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PARTIAL LIST OF SUPPLIERS: BATCH-CONTROL 
SOFTWARE AND SYSTEMS 

ABB (http://www.abb.com/) 

Emerson (http://www2.emersonprocess.com/) 

GE (http://www.ge.com/) 

Honeywell (http://www51.honeywell.com/) 

Invensys (http://www.icca.invensys.com/) 

Rockwell Automation (http://www.rockwellautomation.com/) 
Siemens (http://www.siemens.com/) 

Yokogawa (http://www.yokogawa.com/) 

Batch-Control and Management Software 

Aspen Technology (http://www.aspentech.com/) 

OSIsoft (http://www.osisoft.com/) 

Proleit (http://www.proleit.com/) 

SAP (http://www.sap.com) 

Werum Software & Systems (http://www.werum.com/) 

In continuous processes, such as the distillation of crude oil 
or the manufacture of bulk chemicals and fertilizers, the 
product is manufactured continuously. In batch processes, 
used in food, pharmaceutical, and fine chemical industries, 
products are manufactured in groups called batches. Batch 
processes are sequential, where the control functions (called 
phases), such as charging, mixing, heating, cooling, and test- 
ing, are performed in an ordered fashion. Each phase may 
require many process steps, such as the opening and clos- 
ing of valves, starting and stopping of pumps, and setting 
and resetting of control loops. In addition to the normal step- 
by-step control actions, batch-process control requires many 
other functions, for example, responding to abnormal or fail- 
ure conditions, keeping batch records, maintaining recipes, 
and scheduling batches. 

Batch-process control is a complex task rather than a dif- 
ficult one. A difficult problem is one, which is mathemati- 
cally or scientifically difficult to solve, and usually has a 
single solution. A complex problem, on the other hand, is 
logistically more challenging. It is characterized by numer- 
ous interrelationships and constraints, with mutually exclu- 
sive objectives and many possible solutions. The solution of 
a complex problem involves breaking it down into simpler 


functional modules and finding their proper integration with 
each other. 

Many factors are currently stimulating the demand for 
batch-control systems in North America, Europe, and ulti- 
mately the rest of the world. There is a growing need for 
products to be traceable to their source. The approval of 
electronic batch record (EBR) and electronic signature by 
the Food and Drug Administration (FDA-USA) in the United 
States has given a greater incentive for regulated industries, 
such as pharmaceutics and biotechnology, to move to paper- 
less systems. Many companies in these regulated industries 
are already using electronic data collection to produce paper 
records. These electronic -paper systems must be validated 
and made compliant or be replaced by a system capable of 
compliance. This is leading to increased investments in auto- 
mating and upgrading their control systems. 

Growth of e-business and the need to optimize the supply 
chain are increasing the need for real-time plant and produc- 
tion information, which is fueling the growth of manufactur- 
ing automation and its integration to business system. Market 
globalization and increased competition are intensifying the 
need for multifunction plants with improved operational effi- 
ciencies. In turn, these are increasing the need for more effi- 
cient and flexible manufacturing. 


BATCH-CONTROL STANDARDS 

The ANSI/ISA-88 (IEC 61512) batch-control standard [1-4] 
was developed to provide guidance to users and suppliers 
of batch-control systems worldwide. The standard is in four 
published parts (Table 10.1). 

Part 1: Models and Terminology 

Part 1 of the standard defines the basic terminology and a 
number of models for batch control. The key models are pro- 
cedure, physical, and control activity (as in Figure 10.1). Most 
major suppliers of control systems have adopted standard 
terminology and have designed batch-control systems using 
these three models as a basis. This modular structure allows 
easier integration of third-party packages that provide func- 
tions, such as production planning, scheduling, and produc- 
tion information management. It also makes a batch-control 
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TABLE 10.1 

Batch-Control Standards 




Batch Standard Year Published 

U.S. Standard 

International Standard 

Scope 


Part 1 

1995 

ANSI/ISA-88.00.01 

IEC 61512-01 

Models and terminology 

Part 2 

2001 

ANSI/ISA-88.00.02 

IEC 61512-02 

Data structures and language guidelines 

Part 3 

2003 

ANSI/ISA-88.00.03 

IEC 61512-03 

General and site recipes 

Part 4 

2006 

ANSI/ISA-88.00.04 

IEC 61512-04 

Batch production records 


Procedure Physical Control activity model 



FIG. 10.1 

Batch standard models. Arrows show relationships, not data flow. 

system easier to integrate with production management and 
business planning systems. 

Main benefits of Part 1 of the batch control standard 

• Improved communication between suppliers and users 
of batch control 

• Easier identification of end user needs 

• Straightforward recipe development 

• Reduced cost of automating batch processes 

• Reduced life-cycle engineering effort 

Part 1 of the batch control standard, which was published in 
1995, is currently being revised. The proposed updates are 
not expected to alter the basic concepts of batch control that 
are in the current standard. The updated standard was pub- 
lished in 2010. 

Part 2: Data Structures and Guidelines for Languages 

The ISA-88 Part 2 of the batch control standard focuses on 
data models, information exchange tables, and procedure 
function charts (PFCs). The data models section provides 
formal representation of entities specified in Part 1 of the 
standard, such as recipe, equipment, planning and schedul- 
ing, and information management using Universal Modeling 
Language (UML) notation. The information exchange section 
uses Sequential Query Language (SQL) relational tables to 


specify exchange requirements between recipes, process 
equipment, schedules, and batch production (Figure 10.2). 

The final section of the standard deals with a graphi- 
cal representation of procedures using PFC notation 
(Figure 10.3). PFC is somewhat similar to sequential function 
chart (SFC) notation as defined in the IEC 61131-3 standard 
[5]. PFC notation addresses procedural control and execu- 
tion, while SFC notation was developed primarily for state 



FIG. 10.2 

Data transfer using exchange tables. (© Copyright 2001 ISA — The 
International Society of Automation. All rights reserved. Used with 
permission. From ANSI/ISA-88.00.02-2001, Batch Control Part 2: 
Data Structures and Guidelines for Languages. For information, 
contact ISA Standards, www.isa.org) 
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FIG. 10.3 

Example ofPFC. 


machines. PFC notation meets the requirements of a recipe 
procedure better than an SFC. 

PFC notation is intuitive and easy to follow. Users famil- 
iar with SFC notation will find many similarities between 
the two. However, explicit specification of functions such as 
process equipment allocation and synchronization of phases 
makes PFC easier to follow than SFC notation. 

Providing tools for information exchange, as specified in 
the standard, are allowing suppliers to design more modu- 
lar batch-control systems. This will reduce the high cost of 
maintenance and version upgrades. 

Part 3: General and Site Recipes 



Generic and 
transportable 


Specific and local 


Part 3 of the batch control standard deals with the general 
and site recipes. Recipes can be of four types: general, site, 
master, and control (Figure 10.4). They are identified in Part 
1 of the ISA-88 batch control standard; however, there are 
few details about them in either Part 1 or Part 2. Part 3 of 
the batch standard, which was published in 2003, deals with 
these functions. 

A general recipe is an enterprise-wide recipe for a man- 
ufactured product that serves as the basis for both site and 
master recipes. Chemists and chemical engineers with inti- 
mate knowledge of both the product’s chemistry and process- 
ing requirements are generally responsible for creating it. It 


FIG. 10.4 

Recipe model. 

identifies raw materials, their relative quantities, the required 
processing, and the order of processing. It may define the 
processing capabilities required, such as cooling or heating, 
or the generalized equipment requirements, such as glass- 
lined reactors, but do not define the specific equipment that 
may be used to manufacture the product. A general recipe 
may also serve as input for corporate production planning 
and standard costing procedures. It is usually the parent of 
site and master recipes. 
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FIG. 10.5 

Mapping between general/site recipes and master/control recipes. 

A site recipe has the same structure as a general recipe, 
but the information in a site recipe is tailored for each manu- 
facturing location. A site recipe may be modified for the local 
language, units of measure, regulations, and raw material 
variability. A site recipe may include only a part of a general 
recipe that is actually implemented on the site. For example, 
a single product may have intermediate materials manufac- 
tured at one site that are then shipped to a second site for final 
processing. In that case, each site recipe would be derived 
from only the portion of the general recipe actually required 
for the processing to be done at that site. 

In the increasing complexity of global manufacturing, 
many process manufacturers find it challenging to maintain 
a single definition of a product in different manufacturing 
facilities. General and site recipes provide an equipment- 
independent means of describing batch-manufacturing 
processes. A standardized general recipe acts as a central 
repository for product manufacturing information. The site 
recipe acts in a similar fashion for a manufacturing site. The 
creation of the general and site recipes, taken together accel- 
erates both time-to-market and time-to-volume production. 

General and site recipes contain the same categories of 
information, such as header, formula, procedure, equipment 
requirements, and other information, as in master and control 


recipes. The procedure elements of general and site recipes 
map well with master and control recipes (Figure 10.5). 

Part 4: Batch Production Records 

Part 4 of the batch control standard provides a reference model 
for developing applications for the storage and exchange of 
batch production records. Implementations based upon this 
standard facilitates the retrieval, analysis, and reporting of 
batch production record data. The standard is intended to be 
used as a reference model for the creation of detailed speci- 
fications for the data that make up batch production records. 

Batch production records contain batch production infor- 
mation and related business information. That may include 
the detailed record of the production of a batch, storage, and 
handling of a material, as well as production-related activi- 
ties of a set of equipment, a person, or a group of persons. 
Batch production may involve multiple control systems, other 
related equipment, and manual actions. Therefore, batch pro- 
duction information may be spread across multiple computer 
systems and also on paper. The batch production record 
standard allows improved communication within a single 
manufacturing site, across a corporation, between corpora- 
tions, and between corporations and government or regula- 
tory agencies. 

Figure 10.6 illustrates data flows associated with creat- 
ing, maintaining, and using a batch production record. Of 
these functions and data items, only the batch production 
record is defined in this standard. The other functions and 
data items are only shown to illustrate the environment that 
batch production records are used in. 

Benefits of Standards Reach beyond 
Batch-Process Control 

The benefits of the ANSI/ISA-88 (IEC 61512) standard go 
beyond batch-process control. Although the standard is pri- 
marily designed for batch processes, it is also being applied 
successfully in various other manufacturing industries. 
The standard is applicable not just to software, equipment, 
or procedures but can be used to conceptualize production 
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Production 

information 



Reports 


TO. 10.6 

Production record dataflow. 
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processes thus helping to better design manufacturing plants 
and processes. 

The data models and information exchange tables provide 
significant advantage in the automation and modularization 
of any manufacturing process. The shift from monolithic- 
centralized control architecture to a modular architecture 
allows a process to be more flexible in manufacturing differ- 
ent products and allows for easier maintenance and upgrade 
of control systems. It also facilitates the exchange of infor- 
mation between different systems. Other areas where batch- 
control standards and their underlying concepts may be used 
include 

• Startup and shutdown of continuous processes 

• Material handling 

• Changing products and product grades 

• Alarm and exception handling 

• Product packaging 

The PackML working group within the open modular archi- 
tecture controls (OMAC) organization is using the batch con- 
trol standard as the basis for defining a more flexible use of 
packaging systems in order to ensure consistency and quality. 

Glossary of Common Batch Terms 

Following are explanations of common batch-control terms, 
simplified for easier understanding. For more rigorous defini- 
tions, refer to batch-control standards [1-4]. 

Batch: A quantity of material produced by the single execu- 
tion of a batch process. A batch also refers to the intermediate 
materials during the manufacturing process. 

Control module: A set of equipment and functions that can 
carry out basic control. For example, a control loop consist- 
ing of one or more sensors, actuators, and control functions 
is a control module. 

Control recipe: An equipment specific recipe that defines the 
production of a single batch. It is usually derived from a mas- 
ter recipe. 

Equipment module: A group of equipment that can carry out 
a finite number of specific minor processing activities. 

It is typically centered on a piece of process equipment, 
such as a weigh tank, heat exchanger, filter, and weighing 
scale. An equipment module may include one or more control 
modules. 

Exception handling: Procedures and functions that deal with 
conditions that are outside the normal or desired behavior of 
a process. 

Formula: A part of recipe that includes information on pro- 
cess inputs, process parameters, and process outputs. 

Process input: Identity and quantity of raw materials and 
other resources required to make a batch. Other resources 
include energy and manpower requirements. 


Process output: Identity and quantity of products and/or 
energy produced at the end of a batch. 

Process parameter: Variables, such as temperature, pressure, 
and time, which are set points and comparison values that are 
needed for the production of a batch. 

General recipe: A type of recipe that expresses equipment 
and site independent processing requirements. It is the high- 
est level of recipes. 

Lot: A unique amount of material having a set of common 
traits. Generally, they are products produced by a set of simi- 
lar batches, usually using the same master recipe. 

Master recipe: A type of recipe to produce a batch of prod- 
ucts by using a particular set of process equipment. 

Operation: A procedure that controls the execution of a num- 
ber of phases in a batch. 

Phase: A set of logic steps that completes a major processing 
function, such as charge, mix, heat, and react. At the end of a 
phase, a batch is usually in a stable state. 

Process cell: A set of equipment required for production 
of one or more batches. It usually consists of one or more 
units. 

Recipe: A set of procedures and formula variables that spec- 
ify the production of a batch. There are four types of recipes: 
general, site, master, and control. 

Site recipe: A recipe that includes site-specific information, 
such as local language and locally available raw materials. 

Unit: A collection of process equipment with its associated 
equipment modules that can be used for major processing 
activities. 

Mixers, storage tanks, and reactors are examples of units. 
The associated equipment modules include pumps, valves, 
heat exchangers, and agitators that are closely associated 
with the major process equipment. Units operate relatively 
independently of one another. 

Unit recipe: A part of a recipe that defines a part of batch 
production requirements within a unit. It usually includes a 
number of operations and phases. 

OTHER RELATED STANDARDS 

IEC 61131-3: PLC Programming Language Standard 

The intent of the IEC 61131-3 is to provide general program- 
ming compatibility between different brands of programma- 
ble logic controllers (PLCs) [5], With IEC 61131-3, it should 
be possible, for example, to transfer code written for one 
brand of PLC to another. Flowever, the standard can also be 
applied in the distributed control system (DCS) environment 
to similar advantage. The programming languages specified 
in IEC 61131-3 have widely been accepted for specifying 
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FIG. 10.7 

Example of an LD. 


sequential steps in recipes and phases [3]. It defines two tex- 
tual and two graphical languages. 

Textual Languages 

• Instruction list (IL) is similar to assembly language 
with only one operation per line. It is useful only for 
relatively simple logic control or safety interlocks that 
are repeated often. It is not commonly used in pro- 
cess-control applications. 

• Structured text (ST) is a high-level block structure lan- 
guage similar to Pascal that can be used to express 
complex statements. Structured text can handle a wide 
range of different data types including analog and dig- 
ital values. The language also has support for iteration 
loops and conditional tests. 


Graphical Languages 

• Ladder diagram (LD) is used in PLCs and is a favorite 
with electricians and electrical maintenance organiza- 
tions. Ladder diagrams use standard graphic symbols 
that are laid out in a manner similar to rungs of relay 
ladders, which are bounded in both sides by power 
rails (Figure 10.7). 

• Function block diagram (FBD) is a graphic language 
that allows program elements that appear as blocks to 
be connected together. Other programming language is 
used within a block to carry out the specified function. 
Function blocks are commonly used as standard blocks 
in DCS and PLCs to execute common functions, such 
as PID control. Boolean logic, and others (Figure 10.8). 

The standard also specifies SFC, which is not a standalone 
language but is used as a way to organize process-control 
actions in an orderly fashion. Using the other four languages 
as a base, SFCs partition a program into a set of intercon- 
nected steps and transitions (Figure 10.9). 

In North America, ladder diagram has been the language 
of choice for PLC programming, while FBD is more com- 
mon in Europe. Most of the PLC suppliers are now offering 
IEC 61131-3 standard compliant programming languages. 
The DCS suppliers are also getting into the act by providing 
one or more of these standard languages for the configuration 
of their controllers. 

IEC 61499: Function Block Standard 

IEC 61499 is a new standard that specifies a function block 
oriented paradigm for industrial process control [6]. It is 
based on the programming language and models defined in 
the IEC 61131-3 standard. In addition to real-time control, the 
IEC 61499-based function blocks offer portability, interoper- 
ability, and dynamic reconfigurability. 



FIG. 10.8 

Example of an FBD. 
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FIG. 10.9 

Example of an SFC. 


The primary purpose of IEC 61499 is not to specify a 
programming methodology, but rather, to offer architecture 
and models for distributed control. The standard defines 
these models in terms of function blocks. These models 
can describe DCSs in an unambiguous and formal manner. 
Having a formal and standard approach for describing a sys- 
tem allows them to be simulated, validated, compared, and 
understood more easily. It is then possible to translate this 
model into programming codes, which can be embedded into 
physical devices in a DCS. IEC 61499 is a generic standard 
and therefore does not attempt to define domain-specific enti- 
ties. It can be used to encapsulate, reuse or deploy real-time 
functionality based on the IEC 61131-3 languages. The IEC 
61499 standard is in four parts: 

• IEC 61499-1: Architecture 

• IEC 61499-2: Software tools requirements 

• IEC 61499-3: Tutorial information (application 

examples) 

• IEC 61499-4: Rules for compliance 

The basic component in the IEC 61499 standard is the func- 
tion block (FB). An FB is a self-contained (encapsulated) 
software function, with specified Event and Data interfaces 
(Figure 10.10). Typically the software function is written in 
an IEC 61131-3 compliant language. A trigger in one of the 
event inputs may start the execution of the program, which 
may process input data, generate output data, or output events. 

Typically, batch processes are distributed where raw 
materials flow from tanks to multiple process vessels, such 



Event flow 

► 


Data flow 

► 


FIG. 10.10 

Example of a basic FB. 

as blenders, reactors, and extruders and then to storage areas. 
Thus, the distributed architecture as specified in the IEC 
61499 standard offer significant advantages in designing the 
control of such systems. 

ISA 95: Control and Enterprise Integration Standard 

Although both business and control systems have evolved 
independently, they need to exchange data seamlessly to be 
able to work in a cooperative fashion. This necessity led to 
the development of ANSI/ISA-95.00.01-2000 standard (IEC 
62264) integration standard [7] (Figure 10.11). 

The scope of ISA-95 standard includes 

• Defining an abstract model of the control domain and 
identifying target domains to which it will interface 

• Establishing common terminology for the description 
and understanding of the control domain and its infor- 
mation exchange 

• Defining electronic information exchange between 
the control domain and target domain including data 
models and exchange definitions 

It provides standard terminology and a consistent set of con- 
cepts and models for integrating control systems with enter- 
prise systems. The models and terminology emphasize good 
integration practices of control systems with enterprise systems 
during the entire life cycle of the systems (Figure 10.12). 

The second part of the standard was published in October 
2001 [5]. Part 2 does not add any significant new concepts to 
the integration model. Rather, it contains additional details and 
examples to help explain and illustrate the objects in Part 1. 

The ISA-95 standard defines electronic exchange for- 
mats for shared information, and emphasizes good integra- 
tion practices between enterprise and control systems during 
design and operation. The goal of the standard is to improve 
existing integration capabilities of manufacturing control 
systems with enterprise systems. 

The ISA-95 standard complements the ISA-88 batch con- 
trol standard by establishing a standard data definition for 
the interface between batch automation systems and business 
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FIG. 10.11 

Enterprise-control domain. (© Copyright 2001 ISA — The International Society of Automation. AH rights reserved. Used with permission. 
From ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Part 1: Models and Terminology. For information, contact ISA 
Standards, www.isa.org ) 



FIG. 10.12 

Enterprise-control functional model. (© Copyright 2001 ISA — The International Society of Automation. All rights reserved. Used with 
permission. From ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration Part 1: Models and Terminology. For information, 
contact ISA Standards, www.isa.org) 


systems. It also encompasses other control aspects of a 
manufacturing company seeking to meet the general goal of 
enterprise-wide automation. 

The ISA-95 standard goes a long way in satisfying a vital 
need for common terminology and models for enterprise and 
plant systems integration. Manufacturers feel positive that 


integration is no longer amorphous but follow a consistent 
methodology similar to the ISA-88 batch-control standard. 
It also enables users to better identify their needs and, thus, 
reduce lifecycle engineering efforts. It has also made it easier 
for suppliers to provide appropriate tools to integrate plant 
operations with the enterprise system. 
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B2MML: Business-to-Manufacturing 
Markup Language Standard 

Business-to-manufacturing markup language (B2MML) is 
an extensible markup language (XML) implementation of 
the ISA-95 (IEC 62264) standard. B2MML consists of a set 
of schemas written using the World Wide Web Consortium’s 
XML schema language (XSD) that implement the data mod- 
els in the ISA-95 standard. B2MML has set up grammar and 
message structure, for manufacturing data and how manufac- 
turing and business systems communicate. Applications can 
identify data by name rather than by location. 

The standard definitions for data and processes in 
B2MML offer interoperability between computer systems, 
thus reducing the costs and risks of systems integration. 
This also increases the flexibility of integrating disparate 
production and enterprise management systems throughout 
a manufacturing enterprise and its supply chain. B2MML 
was developed by WBF — The Organization for Production 
Technology. 

Companies interested in following ISA-95 for integra- 
tion projects may use B2MML to integrate business systems 
with production management and control systems. B2MML 
is a complete implementation of ISA-95 as documented in 
the completeness, compliance, and conformance statement, 
which is part of the B2MML download. Any company may 
use B2MML royalty-free, provided due credit is given to the 
WBF. A comprehensive account of B2MML is available in 
the WBF website [8]. 


MODELS 

This section discusses briefly the main models that are speci- 
fied in the Part 1 of the batch control standard, namely: physi- 
cal, control activity, and procedure. As stated before, these 
models help modular decomposition of batch-control prob- 
lems and allow suppliers and users to maintain a common 
view of batch control (Figure 10.1). 

Physical Model 

This model shows the physical hierarchy in a process indus- 
try. In this model, commands flow from higher to lower 
levels, while information flows from lower to higher levels. 
This model generally fits well with the batch manufactur- 
ing processes. Each manufacturing area may be divided into 
a number of process cells, where each process cell has the 
necessary equipment and resources to complete a batch. A 
process cell consists of a number of units, such as storage 
tanks, mixing tanks, and reactors. 

A unit may also include a number of process equipment 
or equipment modules, such as agitators, heating systems, 
pumps, valves, and the like. However, an equipment mod- 
ule may exist independently, which may be used by multiple 
units. A control module, which is either a loop or a device. 


can be a part of an equipment module or can be directly 
associated with a unit. A control module may include mea- 
suring elements, such as thermocouples and orifice plates, 
and control elements that manipulate process variables, such 
as control and on/off valves. 

A unit may not acquire another unit but may request its 
service (e.g., to supply a measured amount of ingredient or 
to accept its product). The control of a unit is carried out by 
the unit supervision function, which is responsible for acquir- 
ing common resources, carrying out inter-unit communica- 
tions, and performing the step-by-step control actions for the 
execution of a phase. 

Control Activity Model 

The control activity model shows the hierarchy of batch-con- 
trol functions. This model shows the hierarchical nature of 
batch control and thus allows a batch-control problem to be 
broken up into multiple levels for analysis, specification, and 
design. The need and functional importance of these levels 
may vary between applications. It should be noted that the 
desired speed of response of a control system changes as we 
move from the lower to higher levels. Thus, the lower three 
levels, process management, unit supervision, and process 
control act in real-time, while transactional type processing 
is more appropriate for the upper levels. Each of the functions 
in the control activity model may be resolved into a number 
of sub-functions. 

Procedure Model 

A recipe procedure, which is part of a procedure model, may 
consist of a number of unit procedures. A unit procedure 
specifies the order of the functions (operations) that are to be 
carried out within a unit to manufacture a batch of product. 
An operation specifies the order of phases, such as charge, 
heat, mix, and store that are carried out within a unit. 

In addition to procedures, a recipe contains a header, for- 
mula, equipment requirements, and other information. The 
header may contain information, such as product and grade 
identifiers, originator, and date of issue. Formula includes 
information on process inputs, process parameters, and pro- 
cess outputs. The equipment requirements specify the type 
and size of process units, as well as other equipment-related 
constraints such as the materials of construction. The other 
information category includes batch-processing support 
information that is not contained in the other parts of the 
recipe. Examples include compliance information, safety 
information, and product-labeling information. 

PROCESS CELL 

A process cell is defined as a set of equipment required for 
production of one or more batches. It usually consists of one 
or more units along with their associated equipment modules. 
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A cell may be classified in a number of ways. One way is 
by product variation, such as 

• Single product of same grade 

• Single product in multiple grades 

• Multiple products in multiple grades 

A process cell that is set up to produce a single product of the 
same grade requires only one order of processing operations. 
Here, a single recipe is required along with one set of formula 
variables. When a batch size is changed, the raw materials 
are scaled accordingly. In many such applications, the for- 
mula variables may be embedded in instructions within the 
phases. A process, which produces a single product in many 
different grades, requires a single recipe with multiple sets of 
formula variables. For manufacturing many products in mul- 
tiple grades in the same process cell, multiple sets of recipes 
are required. Where, the order of the operations and phases 
and the formulas may vary from product to product. 

Physical Structure of a Plant 

Another way to classify a process cell is by its physical struc- 
ture, in terms of the following: 

• Single stream 

• Parallel stream 

• Multiple path 

In a single-stream structure, the units are ordered serially in 
a single train (Figure 10.13). A batch moves from one unit to 
another in the predetermined serial order. Whereas, a parallel 


structure is like a multiple single-stream configuration in 
which there may be common raw material and storage areas 
(Figure 10.14) but otherwise each stream is isolated from the 
others. In a multiple-path structure (Figure 10.15), the move- 
ment of a batch is not along any fixed path. The choice of a 
downstream unit is based on the availability of a unit of the 
right type. The selection of the units may be made either at 
the start of a batch, as and when required by an operator, or 
by a predefined algorithm. 

A piece of equipment or service that is used by more than 
one unit is called a common resource. Common discharge 
pumps or common steam headers for multiple units are 
examples of common resources. A resource that can be used 
by only one unit at a time is called an exclusive-use resource. 
A resource that can be used by several units at a time is called 
a shared-use resource. In the case of a shared-use resource, 
there may be limitations on its capacity to serve. Thus, the 
common steam header may not be able to heat more than 
a certain number of units at the same time. In the case of 
an exclusive-use resource, book and release mechanisms pre- 
vent its use by more than one unit at a time. A shared-use 
resource requires mechanisms to protect it from exceeding 
its capacity. 

SYSTEMS FOR BATCH AUTOMATION 

The types of control equipment commonly used for batch 
control are 

• Programmable logic controller (PLC) 

• Personal computer (PC) 



FIG. 10.13 

Single-stream structure. 




FIG. 10.14 

Parallel-stream structure. 
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FIG. 10.15 

Multi-path structure. 


• Distributed control system (DCS) 

• Programmable automation controller (PAC) 

In a PLC, the traditional programming environment is ladder 
logic or other languages specified in the IEC 61131-3 stan- 
dard [4], A ladder logic environment is well suited for safety 
interlocks, as these functions do not change with the state of 
a batch or the product being manufactured. For sequential 
control functions, which require step-by-step control actions, 
ladder logic can be obscure and difficult to follow. In addi- 
tion, maintaining ladder logic for complicated processes can 
be expensive. Traditionally, PLCs excel in logical control but 
are weak in their continuous control capabilities. However, 
these characteristics are changing with the addition of new 
functions and programming environments, which include 
high-level procedure-oriented languages, block structures, 
and SFC representations. In addition, PCs are now commonly 


used as front-end devices to serve as programming and 
human interfaces. 

A PC may also be used as a stand-alone controller 
where it is directly connected to input/output multiplex- 
ers. Small batch systems may be controlled in this fashion. 
Windows operating system is often used, but capabilities of 
these systems are generally limited because of its size and 
throughput, as well as due to the limitations of the operat- 
ing system. 

In a DCS, the control is distributed into a number of con- 
trol modules. There are a number of significant advantages of 
a DCS over a centralized control system, such as increased 
availability, ease of incremental expansion, and ease of inter- 
facing with foreign devices. The capabilities of a contem- 
porary DCS include standard communications protocols, 
industry standard operating systems, and open information 
access throughout the system (Figure 10.16). 


Business 

systems 


Ethernet 


Production management 




FT (option) 
APIs 


Common Information Infrastructure 


Process control 


Application 

specific 

appliances 


1 


PAC 




OPCDx 


Profibus 
DeviceNet 
Other buses 
Discrete control 


FIG . 10.16 

Typical DCS for batch control. 
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Such a system allows easy partitioning of a batch-control 
task horizontally and vertically. The horizontal partitions, 
based on physical model, are process cells, units, subunits, 
loops, and devices. The vertical partitions, based on con- 
trol activity, are process management, unit supervision, 
sequential/regulatory control, discrete control, and safety 
interlocking. 

A PAC combines the features and capabilities of a 
PC-based control system with that of a typical PLC. Thus, 
a PAC offers not only the reliability of a PLC but also the 
task flexibility and computing power of a PC. PACs are most 
often used in industrial settings for process control, data 
acquisition, remote equipment monitoring, machine vision, 
and motion control. Additionally, because they function and 
communicate over popular network interface protocols like 
TCP/IP, OLE for process control (OPC) and simple network 
time protocol (SNTP), PACs are able to transfer data from 
the machines they control to other machines and components 
in a networked control system or to application software and 
databases. A PAC at the core of an automation system can 
integrate multiple fieldbus networks like RS-485, RS-232, 
RS-422, CAN (controller area network), Ethernet, EtherNet/ 
IP, and others. 

BATCH-CONTROL FUNCTIONS 
Interlock 

Interlock functions enforce plant- and personnel-related 
safety and are generally not dependent on the product or the 
state of the batch under manufacture. Thus, these interlocks, 
once set, are kept active all the time and are changed only 
when changes to the plant configuration or personnel-safety 
considerations warrant it. These functions generally over- 
ride other interlocks that may be active only during certain 
process phases or conditions. A simple example of such an 
interlock is if a pump (PI) has two outlet valves (VI and V2), 
which are feeding two tanks. In such a case, the pump should 
be switched off if both the valves are closed. This can be 
expressed by the Boolean equation 

P 1 off = Vl close d and V2 dosed (10.1) 

Another way to specify interlock functions is by ladder logic. 
Because of the importance of interlocks in terms of safety, 
many users implement them using distinct hardware mod- 
ules, either within or outside a DCS system. 

Regulatory Control 

Regulatory control serves to keep process variables as close 
as possible to their set points despite process and load distur- 
bances. In a batch process, regulatory control is used exten- 
sively for controlling process variables, such as maintaining 
steady flow during charging, maintaining the agitator speed 


in a tank while mixing, or ramping up the temperature at a 
predetermined rate before reaction. 

PID algorithms are commonly used for regulatory con- 
trol; however, in recent years, many modifications to this 
algorithm have been proposed for improved performance. In 
a DCS, the usual method for configuring control loops is by 
interconnecting inputs and outputs of PID and other blocks. 
In a batch-control system, the activation, deactivation, the 
setting of controller constants, and set points are usually car- 
ried out by steps in a phase-logic. 

Discrete Control 

Discrete control is a term used for controlling process equip- 
ment, which has only a limited number of stable states. On/ 
off valves and manifolds are examples of such equipment. 
The on/off valve (Figure 10.17) has only two states, which is 
manipulated by a contact output (CO). The states of the two 
limit switches specify the state of the valve. In the case of a 
manifold (Figure 10.18), the three states are no flow. Tank A 
to Tank B, and Tank A to Tank C; all other possible states are 
considered abnormal. In a DCS, a control block designed for 
this purpose, such as device block or a valve block usually 
does the discrete control. Some systems allow users to create 
blocks with unique functions. 

In addition, some DCSs allow ladder logic or Boolean 
logic for configuring discrete control. When a large number 
of discrete control functions are required, PLCs are com- 
monly used. In a batch-control environment, steps in phase 
logic usually direct discrete control functions. 

Sequential Control 

Sequential control functions perform real-time control at 
the equipment level to move a process through a succession 
of distinct states. Opening a valve and starting a pump to 

CO 
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Open 
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On 

Off 
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Off 

Off 
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FIG. 10.17 

Operation of an on/off valve. CO, contact output from a controller; 
Cl, contact inputs to a controller, detected by limit switches. 
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FIG. 10.18 

Discrete states of a manifold. 



FIG. 10.19 

Normal and exception logic. 


transfer material from one tank to another and then closing 
the valve and stopping the pump after the transfer is complete 
is an example of sequential control. So also is the setting up 
of regulatory control loops or sending alarm messages to 
operators. 

The sequential control required to manufacture a batch 
is usually divided into a number of phases, such as mix- 
ing, heating, and reacting. A phase consists of a number 
of sequential control steps and can manipulate equipment 
within a unit boundary. When multiple units have to work 
in a synchronized fashion, for example, in the transfer of 
material from one unit to another, each unit will have its own 
phase. These phases may communicate with each other to 
set up the required synchronization via the unit supervision 
function. 

Normal and Exception Logic 

Batch control may be divided into three broad categories 
(Figure 10.19). The function that specifies the standard con- 
trol actions is called normal logic. The function that checks 
the plant and process conditions on a periodic basis is called 
monitor function. Periodic checking of the state of pump 
while a transfer of material is taking place is an example of 
a monitoring function. Unlike a safety interlock, which is 
active most of the time, a monitor function is activated by 
normal logic as and when required. 

When a monitoring function detects a failure condition, 
it invokes the appropriate exception logic. Exception logic, 
as the name implies, specifies control functions that are 
required to take care of failure conditions. Exception logic 
can be simple or elaborate. Sending an alarm to the operator 
and waiting until the device is fixed manually is an example 
of simple exception logic. Shutting down malfunctioning 


equipment and starting up an available spare or initiating an 
emergency shutdown sequence for the whole unit are exam- 
ples of more elaborate exception logic. 

There are many ways of specifying sequential control 
functions, such as flow charts, state charts. Boolean equa- 
tions, ladder logic, SFCs, and the like. Among these, the SFC 
and structured English (Figure 10.20) are more common. 

In a DCS, the normal and exception logic steps are usu- 
ally implemented in a high-level procedural language or in 
a tabular state chart format. In a PLC environment, ladder 
logic and function blocks are commonly used. Block-oriented 
structures for sequence control are becoming increasingly 
common in DCS environments, where each phase is specified 
by a sequence block. Inter-block communications are pro- 
vided by connecting the inputs and outputs of these blocks. 

The sequence logic steps are usually specified in a high- 
level language. Monitor blocks provide monitoring func- 
tions in a block-structured environment; otherwise, tables or 


Minispec for weighing a raw material using the weigh tank 

Get the amount and type of raw material from the control recipe 

Open appropriate raw material tank outlet valve 

Fully open weigh tank inlet valve 

Start the charging pump 

Wait until 90% of the raw material is received 

Throttle weigh tank inlet valve to 10% open 

Wait until 100% of the raw material is received 

Stop charging pump 

Close weigh tank inlet valve 

Close raw material tank outlet valve 

Store the weigh tank amount in batch record 

Inform mixer that weigh tank is ready to charge 

End of minispec 


FIG. 10.20 

Example of structured English. 


© 2012 by Bela Liptak 














10 Batch-Process Automation 185 


Boolean equations are used. Block orientation provides mod- 
ular structure and the ease of inter-block communications. 


UNIT BATCH AND RECIPE MANAGEMENT 

The unit supervision function performs the control func- 
tions in a unit. Each unit has a set of phases (like charge, 
mix, and heat), which includes normal logic, exception 
logic, and monitor functions. The recipe specifies the order 
of these phases and the formula variables for a grade of 
product. Unit management also performs inter-unit commu- 
nications and acquires the services of common resources 
when required. 

The process management function is responsible for the 
manufacture of a batch of product. It allows the selection of 
a batch identifier (name) and a master recipe, either manually 
by an operator or automatically by a higher-level function. It 
generates a control recipe from the specified master recipe 
and maintains it during the course of a batch production. 
It directs the manufacturing of a batch by acquiring units 
as required and executing unit procedures, operations, and 
phases in the order specified by the control recipe. It also sup- 
plies the formula variables to the pertaining phases via unit 
supervision function. Process management allows the scal- 
ing of a batch by proper proportioning of relevant formula 
variables. Process management is also responsible for creat- 
ing and maintaining batch records during the production of 
a batch. 

As stated before, there are four types of recipes: general, 
site, master, and control. The recipe management function 
provides the facilities for generation and maintenance of the 
general, site, and master recipes. The process management 
function creates a control recipe from a master recipe. 

Unit Modes 

The operating conditions of a process unit are broadly divided 
into two different modes: manual and automatic. In the man- 
ual mode, the procedural elements for the unit are executed 
manually. An operator may pause the progression of a batch 
but may not force transitions from one step to the next. While 
in this mode, the process inputs may still be monitored by the 
control system. 

In the automatic (auto) mode, the control system controls 
the production of a batch in the unit. The transitions within 
phase logic are carried out without manual interruption as 
appropriate conditions are met. In some situations, the opera- 
tor may pause the progression, but may not force the transi- 
tion from one step to another. 

Unit States 

Equipment entities, such as units and equipment modules 
may have many different states. The number of possible 


states of an entity varies with its complexity and its appli- 
cation. A simple on/off valve usually has only a limited 
number of states, such as open and close when working 
normally. In the case of a unit, a much larger number of 
possible states have been specified in the batch standard 
(Figure 10.21). 

Initially a unit is in an idle state, which transitions to run- 
ning state at the start of a batch. The running state continues 
as long as the normal batch production continues. Exception 
conditions can cause transition to a state, such as paused, 
held, stopped, or aborted depending on the type and serious- 
ness of the exception condition. The state transition could be 
automatic or manually initiated. Usually there are transient 
states, such as pausing, holding, stopping, and aborting 
before the unit reaches paused, held, stopped, or aborted 
state. The unit may return to running state from a paused or 
held state. However, such transitions are not usually possible 
from states such as stopped or aborted, which may require 
discarding the batch and starting anew. 

As stated, transitions may be automatic if specified in a 
procedure. However, an operator can also initiate a transi- 
tion by manual command. Transitions from paused or held 
to the running state usually require manual permissive. 
Detailed analysis should be carried out during the sequence 
logic design regarding the conditions that may lead to state 
transitions. 


FROM ANALYSIS TO IMPLEMENTATION 

The analysis, specification, design, and implementation of a 
batch-control system are complex tasks. This is largely due 
to the multi-state nature of a batch process, which makes it 
inherently more complicated than a single-state continuous 
process. Batch processes generally need more sophisticated 
human interface than that required for continuous processes. 
Sharing of equipment and services can increase complexi- 
ties, and proper booking and releasing mechanisms are 
required where an equipment or service can only be used 
for a single batch. Taking care of exception conditions can 
get very complicated for a critical process where different 
actions are needed for different alarm conditions and their 
combinations. 

However, the complexities vary significantly from one 
batch process to another. They are typically based on plant 
topology (e.g., single stream, parallel stream, or multiple 
path) and the number of different products manufactured 
using the same equipment. In addition, complexities vary 
according to how critical the process is, the amount of excep- 
tion handling, and the amount and the type of operator inter- 
ventions required. The amount and complexity of exception 
handling for a batch process is also of great significance; 
unfortunately, this point is often ignored at the initial design 
stage. Finally, complexity depends also on the levels of con- 
trol activity functions and the requirements of batch tracking 
and reporting. 
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FIG. 10.21 

Typical unit states. Round shapes specify transient states; square shapes specify end states. 


Methods for Analysis 

The analysis of a batch system requires resolving the problem 
into the various control levels and then, within each level, 
decomposing it into functional modules. The two common 
methods of analysis are called structured analysis and object- 
oriented analysis. 

Structured analysis involves starting from a high-level 
view and deconstructing this into more detailed functions 
[9-11]. The main components in this method are data flow 
diagrams, data dictionary, and minispecs. A data flow dia- 
gram consists of one or more bubbles, each representing a 
function, and arrows representing information or material 
flow (Figure 10.22). The storage of information and mate- 
rial are shown within parallel lines. Each bubble may be 
decomposed into a number of bubbles, each representing 
a sub-function. When a function cannot be decomposed 
any further, a minispec is generated for that function 
in structured English (Figure 10.20) and all data names 
used in these diagrams are defined in data dictionaries 
(Figure 10.23). 


In object-oriented analysis, all functions are defined 
as objects [12,13]. An object mirrors a real-life entity or a 
function and contains the required procedure and data for 
carrying out that function. The key concepts of object orien- 
tation are: 

• Encapsulation 

• Inheritance 

• Message passing 

• Late binding 

Encapsulation, or information hiding, allows for the cre- 
ation of an object with its set of data and procedures 
(Figure 10.24). An object can be asked to do a certain 
function, but the user does not require the knowledge of 
the object’s internals. Similar objects can be specified as 
a class so that their data structure and procedures need 
to be defined only once. Inheritance allows a subclass of 
objects to inherit the data structure and procedures of its 
super-class (Figure 10.25). However, a subclass object can 
have a data structure or procedures of its own, which are in 
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FIG. 10.22 

Example of a dataflow diagram. 


Control recipe = Header + Equipment Requirement + Formula + Procedure 
Procedure = [Operation] 

Operation = [Phase] 

Phase = [Weigh, Charge, Mix, React, Cool, Transfer] 

Formula = [Amount, Mix Time, React Temp, Ramp Rate, Prod Density] 

FIG. 10.23 

Data dictionary. 


Object: weigh-tank 

Data: max-weight; current-weight; status 
Procedure: wait; weigh; deliver 

FIG. 10.24 

Object representation of a weigh tank. 

addition to or instead of those inherited. Message passing 
is telling an object what to do without specifying how to do 
it. Late binding allows resolving the address of an object at 
run time rather than at compile time. This allows the ease 
of adding, deleting, or moving objects without affecting the 
rest of the system. 

Project-Application Specification 

Batch-control design and implementation problems often 
arise because of the lack of clear and detailed definition 
up front. This can be addressed by putting in enough 


effort at the beginning of a project by generating a project- 
application specification (PAS). A PAS usually has three 
main parts [14]: 

• Requirement specification 

• System functional design 

• System acceptance criteria 

The requirement specification is the detailed narrative of the 
requirements with little consideration for the specifics of the 
control system to be used. The requirement specification is 
ideally generated by the user organization before the selec- 
tion of a particular system. This document can then be used 
as a bid specification for the control system suppliers to gen- 
erate quotations. 

The system functional design, which is generated only 
after a specific control system has been selected, specifies 
the detailed design based on the requirement specification 
and the capabilities and constraints of the system chosen. 
The design part of the document is generated by the group 
responsible for integrating the system and doing the applica- 
tion engineering (system developer) and must be approved by 
the user before the actual implementation (configuration and 
coding) starts. 

The final section of the PAS is the system-acceptance 
criteria, which defines the tests that are to be carried out dur- 
ing and after the system has been built to ensure its proper 
functioning. The system acceptance criteria include detailed 
procedures for the systematic testing of all the significant 
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FIG. 10.25 

Example of an object class structure. 


functions. This section should preferably be written jointly 
by the user and the system developer. 

A PAS is a single consistent document for the procure- 
ment and implementation of a batch-control system. It is a 
“living” document that requires updating and modification to 
accommodate changes in requirements. Appropriate mecha- 
nisms for suggesting and approving modifications need to be 
in place during the execution of a project. A PAS requires 
considerable effort and financial investment up front, but the 
return on investment (ROI) is very significant in terms of the 
implementation efficiency and the quality of the product. 

The solution of a batch-control problem requires not 
only the selection of a suitable control system, but also, the 
creation or assembling of appropriate strategies for control. 
Object-oriented environments are changing the way a con- 
trol system is configured and programmed. In the future, the 
competitive advantages of control companies will come more 
from exploiting new software techniques rather than from the 
hardware employed. 

BATCH-CONTROL APPLICATIONS 
Advantages of Using General and Site Recipes 

A general recipe contains generic information for the manu- 
facture of a product and does not include equipment or site- 
specific information. This is the first recipe that is generated 
when a new product is developed at the pilot plant level. The 
general recipe is created by people with knowledge of both 
the chemistry and processing requirements of the product. 
It defines manufacturing specific information. A site recipe 
contains site-specific information that may include peculiari- 
ties of raw material available, types of units that are used, 
and other site-specific constraints. A site recipe is also gener- 
ally derived from a general recipe (Figure 10.4). 

In the increasing complexity of global manufactur- 
ing, many companies find it a challenge to maintain a 
single definition for a manufactured product. General rec- 
ipe meets this challenge as the central repository of prod- 
uct manufacturing information. General recipe lets you 


unambiguously communicate processing requirements to 
multiple manufacturing locations. 

General and site recipes can accelerate volume produc- 
tion and the time-to-market of a new product. They provide 
an equipment-independent means of describing the specific 
processing actions required in manufacturing a product. They 
are also the source of information for enterprise resource 
planning (ERP) bills of material and routing. This reduction 
in time-to-volume production makes manufacturers more 
responsive to customer needs and more competitive with new 
products, thus obtaining faster returns on investments. 

General recipes can significantly reduce the corporate 
information management requirements of an end user. When 
changes to recipes and new product recipes are performed 
manually, it can take a significant amount of time and effort 
to get them written, approved, and sent to production. Once 
there, they still have to be implemented on the local control 
system or converted to manual instructions. Use of the gen- 
eral recipe automates these tasks, cutting the time to full- 
volume production by months. 

Computer-Aided Formulation 

For most process manufacturers, variability in raw materi- 
als and changing customer specifications require frequent 
adjustments in formulas and batches. Computer-aided for- 
mulation tools can achieve major productivity improvements 
by streamlining the development and application of formulas 
and automatically integrating product development informa- 
tion and activities with manufacturing (Table 10.2). 

Clear visibility into the product-development process is 
a key to a company’s success in R&D activity, manufactur- 
ing, and in supply-chain management. The product develop- 
ment process, by its nature, also involves a wide cross section 
of people from various parts of the organization. Marketing 
personnel, for example, will need to understand and clearly 
define the claims associated with newly developed prod- 
ucts. R&D will set technical parameters, specifications, and 
testing requirements. Quality control, legal, and purchas- 
ing departments will ensure local regulatory compliance as 
newly acquired, unfamiliar formulas are introduced into the 
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TABLE 10.2 

Benefits of Computer-Aided Formulation 
Faster time to market for new products 
Reduced material costs 
Lower regulatory-driven costs 

Increased productivity for chemists, food technicians, and schedulers 
Lower losses from work off 

Fewer unexpected scheduling changes from batch non-compliance 
Fewer adjustments per batch, resulting in lower labor and equipment 
costs 

The possibility of using less-skilled employees to adjust batches 


manufacturing and supply-chain processes. The challenge 
is to integrate these separate R&D-driven activities into a 
cohesive, enterprise-wide whole that enables the manufactur- 
ing company to rationalize its product line and supply chain 
quickly, while driving the creation of those competitively 
priced products that customers want (Figure 10.26). 

Traditionally, it has been difficult for product developers 
to share information not just with manufacturing, but also 
even among themselves. Formulas and other product devel- 
opment data are scattered across the enterprise in various 
R&D labs and isolated in spreadsheets, legacy systems, dis- 
organized file cabinets, or lab notebooks. 

Due to the lack of a centralized product development 
information system linked to manufacturing execution 
system/enterprise resource planning (MES/ERP), formulas 
have usually been manually keyed, inevitably creating batch 
errors. A new breed of product development software has 
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FIG. 10.26 

Formulation development. 


emerged that centralizes all product development data, auto- 
mates the product development process, and creates a seam- 
less link between R&D and MES/ERP, ensuring accurate 
and timely communication of new product formulas and 
modifications to existing formulas. 

One technology tool helping manufacturing compa- 
nies address the challenge of meeting their post-integration 
product development information management needs is 
enterprise-wide product development software. It provides a 
common product data repository, tools to help identify ratio- 
nalization opportunities, global access to information, stron- 
ger links to marketing and manufacturing, standardization of 
work processes and approvals, and improved collaboration. 
The combination of these benefits results in a more effective 
business process. 

A formulation package considers a list of constraints such 
as the cost of raw materials and energy usage to calculate 
the minimum-cost formula that meets the product specifica- 
tion. It recommends adjustments to any or all of the ingre- 
dients in a batch to bring it within specification. Advances 
in computing capabilities over the last few years have made 
computer-aided formulation within the reach of most process 
manufacturers. 

In the past, major manufacturers of chemical, pharma- 
ceutical, food and beverage, and animal and pet food manu- 
facturers relied on the acquired knowledge of chemists and 
formulators to develop and maintain their product formulas. 
With the increased use of PCs, some of them have developed 
custom packages to meet their needs. That is now changing 
as a number of suppliers are offering software packages to 
address these issues. 

A computer-aided formulation system cannot replace the 
human judgment of a skilled product development and manu- 
facturing management team. However, it can perform all the 
tedious calculations necessary to convert a specification and 
a set of assumptions into a new product. It can also optimize 
formulas based on various constraints far more quickly than 
is humanly possible. 

Electronic Batch Records and Signatures 

An EBR system with integral electronic signatures is 
becoming a requirement for most batch-control systems 
[15]. This is in part because of the 1997 U.S. FDA ruling, 
U.S. 21 CFR (Code of Federal Regulations) Part 11. This 
regulation stipulates the requirements for creating, main- 
taining, archiving, retrieving, and transmitting electronic 
documentation. That includes criteria for consideration of 
electronic signatures to be the equivalent of full handwritten 
signatures. The regulation affects many batch-processing 
operations in the pharmaceutical, biotechnology, medical 
products, cosmetics, food, and fine chemicals industries 
under the U.S. Federal Food, Drug, and Cosmetic Act and 
the Public Health Services Act. 

U.S. 21 CFR Part 11 provides criteria for compliance of 
all regulated electronic records systems used in an enterprise. 
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It applies to existing and future systems. It includes EBR 
systems used to create paper records with handwritten signa- 
tures or systems with electronic signatures. EBR systems and 
the regulated processes vary from the simple and well-defined 
low acid canned foods process to the more complex one-of-a- 
kind biotechnology-based hormone production process. 

As with any new law, compliance requires interpretation 
and adaptation to individual product-specific manufacturing 
processes. This is, by its nature, a slow process that is fur- 
ther complicated by the diversity of industries and processes 
involved plus the limited resources of users, suppliers, and 
regulators. User industries are continuing to evaluate and 
define the impact on existing and future manufacturing oper- 
ations. Recognizing that installed and currently available 
technology lacks some of the required compliance enabling 
functionality, the FDA has required the pharmaceutical 
industry to complete a gap analysis, develop a plan to achieve 
compliance based on sound scientific assessment of risk, and 
begin execution of the plan. 

The benefit of EBRs over paper records is well docu- 
mented (Table 10.3). It can be even more significant in the 
regulated industries because of the cost and time associated 
with validation and compliance. Site-specific application 
engineering services and documentation of application soft- 
ware are a significant part of the cost of achieving validation 
and compliance. In fact, EBR systems extend beyond EBR 
and security functionality to include the administrative func- 
tionality of EBR systems that automate procedures necessary 
for compliance, such as automated documentation and auto- 
mated validation methodologies. Suppliers of EBR systems 
are continuing to increase their product functionality and 
services capabilities to help reduce implementation and vali- 
dation time and cost. This is most pressing in the pharmaceu- 
tical industry where the reduction of time and effort needed 
in the drug development cycle and being the first to market 
with a new drug are vital to economic success. 

Impact of 21 CFR Part 11 

The impact of increasing FDA enforcement activities is being 
felt on the regulated pharmaceutical and medical products 


TABLE 10.3 

Benefits of EBR and Signatures 

Lower regulatory-driven costs 

Shorten time to validation 

Reduced record keeping costs 

Reduced human errors 

Reduced vulnerability to abuse 

Lower losses from work off 

Increased speed of information exchange 

Improved data integration and trending 

Improved manufacturing and business efficiency 

Improved product safety 


TABLE 10.4 

Impact of 21 CFR Part 11 

Standardizes a global approach to accelerate the utilization of 
automation, with clearly demonstrated benefits 

Provides global economic benefits to manufactures who use 
electronic records and signatures 

Accelerates adoption of additional global products safety standards 
for consumer products 


industries. It is also having an impact on their automation 
suppliers, who are upgrading their products with functionality 
designed to minimize the costs of achieving site-specific and 
product- specific compliance, which includes the predicate 
rules for good manufacturing practices. However, the impact 
of U.S. 21 CFR Part 11 is more far-reaching (Table 10.4). 

Product Safety and Traceability 

Product safety is based on close monitoring of every aspect 
of the supply chain but most importantly the actual manu- 
facturing process. With increased global ingredient procure- 
ment and productization, safety has become a great concern, 
because contaminated food and beverage ingredients and 
products, as well as disease bearing organisms can no lon- 
ger be controlled through traditional geographic isolation. 
Ingredients are procured from many parts of the world and 
packaging protects the quality of the material in the package. 

In most enterprises, product safety and traceability 
extends from development through manufacturing and 
through the distribution channel to the customer. This is 
especially critical in industries where being the first to mar- 
ket determines the success of the enterprise. For example, 
it is estimated that in pharmaceutical industries enterprise- 
centric electronic record systems can significantly reduce the 
time for phase three clinical trials. Product safety and trace- 
ability are very complex issues. They will require substan- 
tial automation of the entire manufacturing process supply 
chain to address this issue, but U.S. 21 CFR Part 11 provides 
the first definitive set of guidelines for records security and 
traceability for both regulated and nonregulated industries 
across the globe. 

The scope of batch-control systems with EBR systems 
will continue to expand both horizontally and vertically 
throughout the enterprise. Horizontally, it extends from 
ingredient specification and receiving through manufac- 
turing, packaging, and warehousing. Vertically, it extends 
from sensor validation procedures to data integration in 
the enterprise business systems. It is likely to include more 
system-wide applications software rather than the currently 
segmented pieces of software. 

Applying Model Predictive Control to Batch Processes 

Model predictive control (MPC), once applied almost 
exclusively to continuous processes, is now being applied 
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successfully to batch-process control. Although MPC 
requires a higher initial investment in terms of dollars and 
implementation time, for suitable applications the advan- 
tages over PID control are worthy of the additional effort and 
expense. Batch manufacturers who use MPC are experienc- 
ing significant benefits in the form of reduced batch cycle 
time, which effectively increases plant capacity without 
increasing capital outlays. Other noteworthy benefits include 
improved product quality and consistency between batches. 
Typical applications that can benefit by adopting MPC tech- 
nology include batch reaction and distillation. 

Batch processes are typically more difficult to optimize 
than continuous processes since they rarely reach a steady 
state. This has resulted in the adoption of inadequate control 
strategies and inefficient utilization of assets. 

MPC is an optimization-based multivariable control 
strategy that uses a mathematical model, incorporated into 
a control system, to predict in real-time the control action 
to be taken in the process. The predictive model represents 
the relationship between the process inputs and the process 
outputs. The MPC has the ability to predict process behav- 
ior and proactively take measures to optimize the control 
functions. 

Independent loop controllers perform poorly when 
attempting to control processes with interacting control vari- 
ables. MPC is capable of providing improved control for this 
situation by anticipating and compensating for interactions 
between variables and control loops. In other words, the pre- 
dictive nature of the process model allows control loops to 
minimize the detrimental influence of a disturbance even 
before the actual affect of the disturbance is felt on the loop. 
In addition, MPC allows the optimization of variables within 
the constraint imposed. 

MPC is equally applicable to single loops where PI or 
PID control performs inadequately because of long dead 
times or large time constants. This situation occurs quite fre- 
quently in manufacturing operations that utilize, among oth- 
ers, batch reaction and distillation. Operations that are prime 
candidates for applying MPC include those that are widely 
used in manufacturing processes and those that account for a 
significant amount of added value. 

Reduced batch cycle time is MPC’s biggest value propo- 
sition for batch manufacturers. For production-constrained 
manufacturing, MPC can provide additional throughput or 
capacity without additional capital expenditures. In addition, 
MPC reduces process variability for improved safety, higher 
quality, and better batch-to-batch consistency. These benefits 
must be weighed against the fact that MPC is more expensive 
to implement due to the need to build a process model and 
may be more difficult to maintain. 

Cost/benefit analysis should be performed to determine 
if the incremental cost of MPC implementation is justified 
relative to the potential benefits. Replacing PID control with 
MPC should be considered if a process is characterized by 
long dead time or time constants. Operator training is the key 
to sustaining the benefits of an MPC project. 


Dynamic Recipe Update to Improve Product Consistency 

Recipe-driven production management techniques have 
and will continue to serve the industry well by improving 
batch-to-batch consistency. The basic method as defined in 
the ANSI/ISA-88 (IEC 61512) standard calls for a four level 
hierarchal recipe approach that includes general, site, master, 
and control recipes. 

Generally, a control recipe created once at the start of a 
batch is not subjected to any modification during the course 
of its manufacturing process. However, in many applica- 
tions, a dynamic control recipe can optimize the quality of 
the product or reduce the time required for the completion 
of a batch. 

The goal of dynamic recipes is to measure the actual 
processing conditions and adjust the recipe formulation to 
achieve the desired outcome. To achieve optimal outcomes, 
control recipes need to be reformulated at the beginning of 
each batch as well as while the batch is running. By detecting 
the initial conditions of things that are not going to change 
during a batch run, but have an impact on the outcome, a 
batch recipe can be reformulated at the start to optimize the 
process. For example, control recipes are generated for a par- 
ticular fixed set of initial conditions such as catalyst activ- 
ity or equipment fouling. Dynamic recipes compensate for 
the fact that these variables may change from batch to batch. 
(Figure 10.27). 

There is also an opportunity to use dynamic recipes 
while a batch is in operation. A batch consists of multiple 
phases with some running simultaneously and others sequen- 
tially. For sequential phases, each successive phase depends 
on the outcome of the previous phase. Currently, control reci- 
pes do not take into account the actual measured outputs, but 
assumes everything proceeded according to plan. Dynamic 
recipes, on the other hand, use actual measured outputs from 
one phase as inputs for the next. In this way, dynamic recipes 
compensate for deviations detected during the batch run. 

Dynamic recipe has been used successfully in differ- 
ent settings. For example, it has been used to considerably 
improve the quality of a silicon wafer manufacturing process. 
Another example is seen in a polymer manufacturing plant of 
a major petrochemical company where the progressive poly- 
mer coat on reactor walls caused changes in heat-transfer 
coefficients after successive batches. This phenomenon led 
to longer residence time in reactors and increases in batch 
cycle time. The problem was solved by a custom dynamic 
recipe application that automatically adjusted temperature 
set points and ramp rates in the recipe’s formula variables 
to compensate for the change in heat-transfer coefficients. 
Shorter batch cycle times resulted from this application of 
dynamic recipes. 

Exploiting dynamic recipes requires adequate per- 
formance measures and targets that represent the overall 
defined objective, along with a process model that incorpo- 
rates how the inputs to each phase are being transformed to 
outputs (now inputs into the next phase). Dynamic recipe 
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Dynamic recipe utilization 
modifies control recipe to 
achieve desired outcome 


FIG. 10.27 

Dynamic recipe. 

update should be considered only for those applications that 
show significant variations in end products or intermediates 
between different batches using the same recipe. Dynamic 
updating of control recipes should be applied only when an 
adequate process model has been built. 

Selecting the Right Key Performance Indicators 
for Batch-Process Optimization 

Key performance indicators (KPIs) help define and measure 
the progress of an organization’s goals. Once an organization 
defines its mission and goals, it needs the ways to measure 
the progress toward these objectives. 

KPIs are developed to measure the extent to which the 
organization is able to carry out its objectives and move 
closer toward its goals. KPIs are quantitative benchmarks 
that help an organization to objectively evaluate whether it is 
making progress. 

A specific batch cycle time might be chosen as a KPI. 
This would have to be further defined by its scope, how it 
will be measured, and targets for improvement. If a KPI is 


going to be of any value, there must be a way to accurately 
define, measure, and use it. KPIs can be used as performance 
management tools for the organization as well as to create 
personnel incentives. 

In terms of the organization level, ROI can be a common 
KPI for many businesses, while the number of clients assisted 
during a given period of time may be the KPI of a nonprofit 
organization. On the personnel level, the KPIs chosen for dif- 
ferent classes of the manufacturing personnel, such as opera- 
tors, production supervisors, plant and mill managers, sales 
and marketing personnel, and corporate executives will vary 
according to what is relevant to their particular output. A KPI 
may change when an organization gets closer to its objective 
or when the goal of the organization changes. 

Many aspects of an organization and its work are mea- 
surable, but not all of them are crucial to an organization’s 
success. In selecting KPIs, it is critical to limit them to those 
factors that are essential to the organization’s goals. It is also 
important to keep the number of KPIs small in order to keep 
everyone’s attention focused on achieving the specific targets 
(Tables 10.5 and 10.6). 

KPIs should give everyone in the organization a clear pic- 
ture of what is important and what they need to do to meet 
the targets. They can be used to manage performance and 
make sure that everyone in the organization is focused on 
meeting or exceeding the defined KPIs. 

OPTIMIZING THE SUPPLY CHAIN 

Supply-chain management is a set of coordinated activities 
that include procuring, manufacturing, storing, and distribut- 
ing. While every factory and distribution center at a large 
manufacturing company can be operating at peak efficiency, 
the organization as a whole can still be operating sub-opti- 
mally. It is analogous to a sports team with individual play- 
ers who have great statistics, but cannot play as a team and, 
therefore, cannot win. Supply-chain management addresses 
this problem by optimizing the performance of the system as 
a whole (Figure 10.28). 

Understanding the type of supply chain that a company 
operates is an important step in its optimization. For some 
industries, the critical constraints are likely to be found in 
procurement, for others it is manufacturing or distribution. 
Manufacturers in similar industries tend to be in the same 
supply-chain segment. 

Distribution-intensive supply-chain manufacturers 
include consumer-packaged-goods producers who must meet 
the demands of large retailers or lose business. In recent 
years, there has been a fundamental shift in market power 
from manufacturers to retailers. Historically, manufacturers 
dictated the terms of trade with retailers and organized their 
businesses primarily to increase manufacturing efficiency 
and output. Today, large chain retailers increasingly are 
choosing suppliers based on their ability to match product 
flow to actual customer demand. 
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TABLE 10.5 

KPIsfor Batch Production 


Attribute 

Key KPIs 


Batch-process 

control 


Recipe 

management 

Production 
planning and 
scheduling 
Quality control 


Batch cycle time 

Cleaning time between batches 

Number of alarms generated during a batch production cycle 
Number of times a batch was held during a batch production cycle 
Amount of time a batch was on hold as a percent of batch cycle time 
Number of operator interventions required during start up, normal 
operation, and shutdown 

Number of operation interventions required during exception conditions 
Asset utilization: the percent of time a process unit is not in an idle state 
Elapsed time between the end of a batch and the start of a subsequent batch 
Products inventory 
Quality deviations 

Amount of quality records that require review 
Time for quality testing and product release 

Percentage of batches that are off specification at the end of a batch and 
require further processing 

Percent of batches that are off specification that need to be discarded 


TABLE 10.6 

Example of KP1 Scope, Measurement, and Target 

KPI Batch Cycle Time 

Defined as Total elapsed time from the start of a batch of a batch through to its completion. It 

includes the time for charging raw materials and transfer of finished products to storage. 
It does not include cleanup time for process vessels, pipelines, and ancillary equipment. 

Measured by The automated batch production recording system maintains records of all batches. The 

start and end time will be extracted from this record for each batch and displayed as a bar 
graph. Monthly averages will also be displayed. 

Target Reduce batch cycle time by 15% within 1 year while maintaining product quality and 

consistency. 


Manufacturing-intensive industries include industrial 
equipment, aerospace and defense, heavy metals, and semi- 
conductors. In this segment, it is not unusual to find manu- 
facturing facilities that cost over a billion dollars. Labor and 
material acquisition costs are relatively less significant. The 
key is to keep those expensive machines up and running, with 
minimum idle time. For this reason, real-time scheduling is 
more important for such companies. 

Companies that compete in industries with short product 
life cycles tend to be in the sourcing intensive sector. The two 
primary industries in this segment are consumer electronics 
and apparel. 

Specialty chemicals, pharmaceuticals, food and bever- 
age, and consumer products constitute a majority of the batch 
processes. Specialty chemicals and pharmaceutical industries 
fall between the manufacturing-intensive and distribution- 
intensive areas, whereas food and beverage and consumer 
products are mostly distribution intensive. Therefore, enter- 
prises with batch manufacturing processes generally require 
optimization in the manufacturing and distribution areas. 


Until recently, process-plant optimization was the main 
focus for control engineers. We were satisfied when the con- 
trol loops were properly tuned and the recipes and phases 
ran in proper order producing products that were within 
the required quality specifications. With globalization of 
the market, increased competition, and the need for custom 
products, batch manufacturers are rapidly moving toward 
flexible just-in-time manufacturing. In this environment, 
supply chain and enterprise-wide optimizations are becom- 
ing increasingly important. It is no longer sufficient for an 
enterprise to have islands of automation along with the iso- 
lated supply chains. In order to maximize the potential of 
batch-process control, manufacturing plants, enterprises, and 
the supply chains need to work together closely in an opti- 
mized fashion (Figure 10.29). 

In this new environment, with integrated enterprises and 
supply chains, manufacturing will continue to maintain its 
central role. In this environment, it is not enough to leave 
the total responsibility of supply chain and enterprise-wide 
optimization to IT personnel, who have little understanding 
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FIG. 10.29 

Three levels of optimization. (© Copyright 2000 WBF. All rights 
reserved. Used with permission. From Ghosh: Maximizing the 
Potential of Batch Processes WBF Conference, Brussels, October 
2000; For information, contact WBF, www.wbf.org ) 


of the manufacturing processes. Today, in order to maximize 
the potential of batch-process control, engineers need to 
broaden their focus considerably in the industry and supply- 
chain optimization areas. 

Process-Plant Optimization 

While today’s engineering design, training, and model-based 
control is converging; it is primarily for the benefit of con- 
tinuous processes. Batch processes bring at least one added 
complexity: they rarely reach the steady state. Batch-oriented 
industries such as pharmaceuticals, fine chemicals, and food 
and beverage have not used simulation-based tools for pro- 
cess optimization and operator training to the same extent as 
their counterparts in the continuous-process industries. 


Since the current optimization technology used in refin- 
ing and other continuous processes must sense steady state 
before they can calculate an optimum, they are somewhat 
limited in their applicability to batch processes. However, as 
stated in an earlier section, MPC is now making headway in 
the batch processes. 

Many manufacturers, however, have found other 
approaches to optimize their batch processes. For example, 
if the best practices of a master brewer can be captured as a 
series of rules, then expert system applications have exhibited 
the ability to optimize the beer production process. 

Other types of simulation and analysis tools also become 
useful when approaching hybrid and batch processes with the 
goal of optimization. Discrete event simulation software can 
optimize the process by which the work is done. In this con- 
text, the word “process” applies to the procedure or methods 
used from start to finish during an operation, whether it is a 
physical process or a human one. For example, raw materi- 
als flowing through a plant that manufactures finished goods 
will encounter many processes or procedures. In question 
are issues such as how many reactors are needed to handle 
a number of batches, how fast a packaging line can move, 
and how many of them are needed to meet the production 
demand. 

Efforts are now being made to integrate planning and 
scheduling tools with on-line batch-control products (Figure 
10.30). It is not difficult to envision how integrated simulation 
and design tools can allow a product introduction cycle of 
18 months to be shortened to as little as 6 months. A phar- 
maceutical company that is trying to beat the competition 
to market with the latest miracle drug could find it is worth 
millions of dollars. 

Enterprise-Wide Optimization 

The primary objective of a manufacturing facility is to add 
value. The function of a business process is to convert this 
added value into profit. That is pivotal for the success of 
an enterprise and it is leading the batch-process industry 
to shift its emphasis from process optimization to business 
optimization. Access to manufacturing data is critical for 
business optimization because continuous improvement is 
based on patterns and relationships contained in this data. 
Manufacturing data originates in plant systems. Enterprise 
integration minimizes or eliminates duplication of data. 

An enterprise needs to understand its manufacturing 
requirements, its business needs, and their relationships 
before it can come up with a viable integration strategy. A 
company may have a corporate business information sys- 
tem or may be in the process of setting one up. It needs to 
determine the type and quantity of information the business 
system will need and provide it to the automation system. 
The information exchange between business and automa- 
tion systems can range from simple production schedules 
to elaborate quality, inventory, and process management 
instructions. The amount and type of information that a 
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FIG. 10.30 

Integrated batch-process optimization. (© Copyright 2000 WBF All rights reserved. Used with permission. From Ghosh: Maximizing the 
Potential of Batch Processes WBF Conference, Brussels, October 2000; For information, contact WBF, www.wbf.org) 


business system will need from the control system can also 
vary widely. They may only be averaged process values or 
could include information on alarm, quality, operator action, 
production record, and materials movement. The amount of 
information exchange will determine the level of integra- 
tion required between the batch automation and business 
systems. 

There are a number of production management functions 
such as quality, documentation, maintenance, production 
scheduling, and quality management. One needs to decide 
whether these functions are to be performed by the business 
system or by the automation system, or partially by both. It 
is important to decide which system will be the main reposi- 
tory for process information. Inventory management and the 
tracking of material movements in production facilities may 
be carried out either by the business system or by the process 
automation system. Often, they are shared by both and their 
interfaces need to be clearly defined. The work of ISA-95 
enterprise-control integration standard is helping us to make 
these decisions. 

Control and Enterprise Synchronization 

Successful integration of a batch-control system with enter- 
prise management requires proper synchronization. There 
are a number of synchronization gaps. Time is an obvious 
gap. While a control system responds in seconds and milli- 
seconds, an enterprise-management system measures its time 


in months, weeks, days, and hours. A control system gathers 
real-time or event-based information with time frames con- 
sistent with plant process dynamics. An enterprise system 
maintains transaction-processing information based on busi- 
ness dynamics. Execution in the enterprise system is oriented 
toward planning and scheduling, while execution is oriented 
toward engineering and control at the plant level. 

The enterprise of the future, however, will need to get 
closer to the essence of optimization. From a front-office 
perspective, this involves optimized planning for business 
requirements. Optimization from a back-office perspective 
involves manufacturing responsiveness to business require- 
ments. For the enterprise of the future to satisfy its perfor- 
mance requirements, the front office and the back office need 
to be synchronized, not in a time sense, but in an information 
sense. Both need to be mutually supportive, driving toward 
the same goals, and operating with the same information. 
This level of optimization requires both business and man- 
ufacturing processes to inter-operate in a single environ- 
ment and information domain. This single environment will 
require a new generation of open plant systems based on a 
common component model (Figure 10.31). 

Cultural gaps between control and business management 
are a major problem in many organizations. Effective inte- 
gration of these two worlds requires significant technical, 
educational, and planning efforts. 

The general and site recipe concepts in the batch-con- 
trol standards and the ISA-95 standard are conceptually 
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FIG. 10.31 

Synchronization of information as needed. (© Copyright 2000 WBF All rights reserved. Used with permission. From Ghosh: Maximizing 
the Potential of Batch Processes WBF Conference, Brussels, October 2000; For information, contact WBF, www.wbf.org) 


helping the integration, while XML, B2MML, and compo- 
nent technology are the main technology enablers. Today, 
a majority of integration with ERP tends to be done on a 
custom basis to solve specific problems. However, standard 
integration products are emerging as enterprise software 
companies develop these interfaces. 

Internet Technology Is the Primary Enabler 

Significant improvements in the supply chain are taking 
place, with Internet technology as the primary enabler. It 
is lowering business cost, extending global reach, increas- 
ing customer responsiveness, and making made-to-order 
manufacturing easier. Manufacturers and suppliers alike 
are rushing to introduce websites and business-to-business 
(B2B) marketplaces that can be used to market and procure 
all types of goods and services. Most manufacturers cur- 
rently offer or plan to offer their own products over the web 
via their own sites. The next move, which has already com- 
menced among leading manufacturers in the automotive, 
aerospace, chemical, and other industries, is to align with 
one of the emerging industry-specific buy-side Internet por- 
tals in order to purchase raw materials, finished parts, and 
subassemblies. The end result is that the Internet is emerging 
as the great equalizer, leveling the playing field of compet- 
ing suppliers and giving the manufacturing customer greater 
visibility and control over a procurement process that should 
ultimately result in improved procurement processes and 
significantly lower prices for purchased goods (Tables 10.7 
and 10.8). 


TABLE 10.7 

Supply-Chain Optimization Benefits 
Lowering business cost 
Extending global reach 
Increasing customer responsiveness 
Allowing made to order manufacturing 


TABLE 10.8 

Supply- Chain Optimization 
Challenges 

Flexible production facilities 
Smaller production lots 
Faster shipments 

Effective information management 
Transaction security 
Change in corporate culture 


The promise of the Internet is much greater than just 
lower prices. Strategic use of web-based procurement capa- 
bilities can drive significant reductions in the costs associ- 
ated with the procurement process itself, including request 
for quote (RFQ), supplier selection, the bid process, and 
supplier management, among numerous other tasks. This 
promise of lower prices coupled with drastically reduced 
procurement process costs is what makes the Internet such a 
powerful force behind the sea of change currently underway 
in procurement strategies. 

A key element fueling the Internet’s proliferation is its 
ease of use and resulting ease of doing business. While some 
manufacturers may not have moved to actually purchasing 
products on the web, a vast majority rely on it to expedite the 
information-gathering phase due to the zero cost and min- 
imal time associated with web research. The web offers a 
speedier and more efficient search process, particularly rela- 
tive to the typical loop of asking the distributor a question 
and then waiting for a response after the supplier gets back 
to the distributor. 

Internally, the greater visibility offered by a web-based 
system allows good control over the purchasing process and 
improved supplier management. Web-based procurement 
introduces lower transaction costs, particularly if the web 
is used to internally standardize, control, and monitor the 
procurement process. Improved control and visibility over 
the procurement process throughout the entire enterprise 
will also result in lower inventory carrying costs since the 
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agile procurement system can monitor inventory levels, time 
elapsed since last purchase, and calculate the optimum time 
to place a new order. 

In the automation space, the Internet has been widely 
used to provide self-service support. This is true at the level 
of both suppliers to user and within manufacturing compa- 
nies themselves, where second and third shift operators can 
access application, machine, or product-specific information. 
Often, no human contact is required. Furthermore, the infor- 
mation required for service or support is available around the 
clock. 

Availability of web-based support and information has 
been a tremendous boom to small and mid-sized manufac- 
turers. With the Internet leveling the playing field, these Tier 
2 and Tier 3 manufacturers are now able to access technical 
databases and other information that was previously avail- 
able only to Tier 1 manufacturers. Some suppliers are using 
this market reach to their strategic advantage. 

Both single supplier sites and multi-vendor B2B mar- 
ketplaces can offer transaction efficiencies through web- 
based selection, procurement, and post-sales support. 
Because they contain the offerings of only one supplier and 
perhaps their partners, however, single supplier sites can- 
not deliver the added advantage of competitive pricing that 
can ultimately drive down the cost. Suppliers may use a 
customer’s private network (extranet) to present customer- 
specific negotiated pricing on its website, but as recent 
experience shows, manufacturers can achieve savings by 
conducting a reverse auction with an RFQ. Moving from 
single supplier sites to a B2B marketplace also shifts the 
focus resoundingly to the buyer’s application requirements 
rather than the sellers and their products. Thus, the Internet 
technology is helping the optimization of supply chain in a 
very positive way. 


FAULT TOLERANCE AND RELIABILITY 

This section discusses briefly the needs for fault tolerance in 
batch-control systems. Safety and reliability are discussed in 
greater detail in Chapters 47 and 48. 

The reliability and fault tolerance of a batch-control sys- 
tem is of greater significance than that for a continuous con- 
trol system. On failure of a batch-control system, the fallback 
device needs to know the exact state of a batch in order to be 
able to continue the production or to bring the process to a 
safe condition. 

The degree of reliability needed for a batch-control sys- 
tem varies with the criticality of the process under control, 
but more importantly, it varies with the different levels of 
control (Table 10.9). Thus, the reliability at the device con- 
trol level is more critical than at the recipe control level. In 
a DCS, where these control levels are controlled by different 
hardware modules, this need for reliability is generally taken 
care of by fault-tolerant pairs as required. In this arrange- 
ment, two identical processors are configured as a married 
pair, where both the processors run in parallel using the same 
inputs, and the outputs of one of the modules is used for con- 
trol at any given time. The outputs of both the processors are 
periodically compared to ensure that they are synchronized 
and are in good health. If they disagree, then diagnostics are 
invoked to allow the good partner to continue the control, 
and appropriate messages are generated to fix the other. 

In evaluating the reliability of a batch-control system, 
both hardware and software reliabilities should be taken 
into consideration. In recent years, the hardware has become 
more reliable and less expensive. This in turn has increased 
the demands for features and capabilities of control system 
and thus has made software effort much larger and more 
complex. The software reliability problem is not similar to 


TABLE 10.9 

Fault-Tolerance Requirements 



Control Level 

Fault-Tolerance 

Requirements 

Ways of Achieving Fault Tolerance 

Sensing elements 

+ 

Minimal for most, critical for a limited number 

Safety interlocks 

+++ 

Manual backup for those not crucial. Double- or triple-redundant 
seasons for the crucial 

Mostly by dedicated hardware modules, within or independent of 

Continuous control 

++ 

the control system 

Backup controller and/or manual control stations 

Device control 

+++ 

Backup controller 

Sequence control 

+++ 

Backup controller or triple redundant system 

Batch management 

++ 

Backup controller where required 

Recipe management 

+ 

Backup controller where required 

Scheduling management 

X 

Manual backup 

Information management 

++ 

Redundant bulk storage and backup processors here needed 

Human interface 

+ 

Multiple human interface equipment (printers, CRT, and keyboards) 

Inter-processor communications 

++ 

Redundant communication channels 


X, little or no requirement; +, same requirement; ++, significant requirement; +++, crucial requirement. 
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FIG. 10.32 

Software error detection curve. 

the hardware reliability problem because software does not 
degrade with use. Unreliability in software is caused by the 
presence of programming “bugs,” which may stay undetected 
even after rigorous testing. 

The reliability of a piece of software is dependent on the 
probability of its performance without fault for a given period 
of time and on the time to correct the fault after its detection. 
While testing a piece of software an error detection curve 
may be drawn (Figure 10.32), which can provide some indi- 
cation of its reliability. 

The standard software modules, such as the operating 
system, control packages, and utilities, are generally more 
reliable as they are used in multiple systems. When an error 
is reported, the system supplier usually generates a correc- 
tion for all the installed systems. However, this is not the 
case with application-specific software, as they tend to be 
unique for each system. In addition, changes in control 
requirements require additions and modifications to exist- 
ing software with the possibility of introducing new bugs. 
The ways for increasing the reliability and modifiability of 
software should be considered early in a project. These ways 
include: 


• Detailed analysis of control problem, breaking it into 
small manageable modules 

• Specification and design of the modules with clear 
definition of their interrelations 

• Proper design reviews 

• Modular programming using off-the-self software 
wherever possible and generating common routines 
for similar functions 

• Desk checking and walk throughs for generated code 

• Rigorous testing of intra-module and inter-module 
functions with appropriate simulations 

The object-oriented approach in specification, design, and 
implementation of software is gaining increased acceptance. 
This forces a modular approach and reduces the duplication 
of common code to a minimum. Object-oriented program- 
ming environments also allow for maintaining libraries of 
objects, which may be used in many different projects, thus 
reducing rework and increasing the software reliability. 

SYSTEM SELECTION CRITERIA 

The selection of an appropriate control system for a manu- 
facturing plant is largely dependent on the type and complex- 
ity of the application. The complexity of an application is 
dependent on many factors such as the plant’s topology, the 
number of different products and grades, the criticality of the 
application, and the size of the plant. 

For batch-control system users, the most important cri- 
terion for the selection of a system is its software and hard- 
ware functionalities, as found in a survey conducted by ARC 
Advisory Group. Additional criteria in order of importance 
are services capability, knowledge of the industry and the 
processes, local support, the cost of application services, and 
cost of hardware and software (Figure 10.33). 

Some batch processes are considered critical because 
control failure may result in hazardous situation, equipment 
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damage, or loss of very high value product. The most com- 
mon hazardous processes involve very fast exothermic 
reactions in which all corrective actions need to be taken 
automatically to ensure a safe operation. The manufacture of 
PVC is an example of a fast exothermic process and pharma- 
ceutical and biotech manufacturing processes involve very 
high value products. Critical applications generally require a 
high level of fault tolerance, a high level of safety interlock- 
ing, and combination of requirements significantly increases 
the complexity of the control extensive exception handling 
logic to take care of abnormal conditions and its solution. 

All major control system suppliers now offer batch- 
control systems that follow ISA-88 standard. In general, the 
functionality offered by one supplier or a system may not 
have a significant advantage over another. Suppliers’ prod- 
ucts leapfrog one another from time to time. A user should 
be looking for its own particular software and system needs, 
a supplier’s service capabilities, application knowledge, and 
experience in the area of manufacturing, and the quality of 
local support. 

Acknowledgments 

The author acknowledges the help and support given by ARC 
Advisory Group. Special thanks to her daughter, Annapurna 
Ghosh, for proof reading and suggesting improvements. 

References 

1. ANSI/ISA-88.00.01-1995, Batch Control Part 1 : Models and 
Terminology , Research Triangle Park. NC: ISA, 1995. 

2. ANSI/ISA-88.00.02-2001, Batch Control Part 2: Data 
Structures and Guidelines for Languages, Research Triangle 
Park, NC: ISA, 2001. 

3. ANSI/ISA-88.00.03-2003, Batch Control Part 3: General and 
Site Recipe Models and Representation, Research Triangle 
Park, NC: ISA, 2003. 

4. ANSI/ISA-88.00.04-2006, Batch Control Part 4: Batch 
Production Records. Research Triangle Park, NC: ISA, 2006. 

5. IEC 61131-3, International Standard, Programmable 
Controllers — Programming Languages, Geneva, Switzerland: 
International Electrotechnical Commission, 1993. 


6. IEC 61499, International Standard, Function Blocks, Geneva, 
Switzerland: International Electrotechnical Commission, 2005. 

7. ANSI/ISA-95.00.01-2000, Enterprise-Control System 
Integration, Research Triangle Park, NC: ISA, 2000. 

8. WBF website: https://www.wbf.org (Accessed April 10, 2011). 

9. DeMarco, T., Structured Analysis and System Design, 
New York: Yourdon Inc., 1978. 

10. Yourdon, E. and Constantine, L., Structured Design, Englewood 
Cliffs, NJ: Prentice Hall, 1979. 

11. Weinberg, V., Structured Analysis, New York: Yourdon Press, 
1980. 

12. Ghosh, A., Object lessons. Chemical Engineering, June 1991. 

13. Ghosh, A., The object is control. Chemical Engineering , June 
1991. 

14. Ghosh, A., Project application specification — What is it 
and why do we need it, Canadian Conference on Industrial 
Computer Systems, Montreal, Quebec, Canada, May 1986. 

15. Guidlines on electronic records and electronic signatures, 
Code of Federal Regulations: 21CFR Part 11, Food and Drug 
Administration, March 1997. 

Bibliography 

ARC Report: Batch Process Automation Strategies, ARC Advisory 
Group, October 1999. 

Coad, P. and Yourdon, E., Object-Oriented Analysis, Englewood 
Cliffs, NJ: Prentice Hall, 1990. 

Fleming, D. W. and Pillai, V. A., S88 Implementation Guide, 
New York: McGraw-Hill, 1999. 

Ghosh, A., Why batch process control is not chemical engineering, 
AIChE Annual Meeting, Los Angeles, CA, November 1991. 

Hawkins, W. M. and Fisher, T.J., Batch Control Systems: Design, 
Application, and Implementation, Research Triangle Park, NC: 
ISA, 2006. 

Rosenof, H. P. and Ghosh, A., Batch Process Automation: Theory & 
Practice, New York: Van Nostrand Reinhold, 1987. 

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, 
W., Object-Oriented Modeling and Design, Englewood Cliffs, 
NJ: Prentice Hall, 1991. 

Smith, D. N., Concepts of Object-Oriented Programming, New 
York: McGraw-Hill Inc., 1991. 

Sommerville, I., Software Engineering, Reading, MA: Addison- 
Wesley, 2006. 

Van Brempt, W. and Vinson, D. R., Advanced process control for 
chemical batch reactors, WBF North American Conference, 
Philadelphia, PA, March 24-27, 2008. 


© 2012 by Bela Liptak 


